Window Scroller
Volume Number: 2
Issue Number: 9
Column Tag: Advanced Mac'ing
Build a Pop-Up Window Scroller 
By Scott T. Boyd, Aggieland, TX
Scott is a graduate student at Texas A&M, doing research in typesetting (TeX) and
object oriented programming. He has a background in VAX/Unix and has done a lot of
work on porting TeX to the Mac, but says the Lisa Compiler bugs derailed that project
until another firm bought the Lisa source and fixed it. In this article, Scott presents a
clever way to pup-up a minature window and scroll directly to the point of interest.
This is ideal for large grafport projects and we are happy to present Scott with our
Program of the Month award and $50 with thanks from MacTutor!
Fig. 1 Getting the Big Picture
Getting the Big Picture
For years computers offered no more user interface than a command line,
single-keystroke menus, and full-screen text editing. The Macintosh has introduced us
to the beauties of carefully designed user interfaces. The average user has come to
expect pull-down menus, windows, a desktop, a pointing device, and other user
interface tools. Apple has provided a set of guidelines for those who would like to
extend the user's mental metaphor by providing new user interface elements.
Many solutions emerge out of the minds of frustrated users. For example, users
of large computers used to have all computer output displayed on one screen in a single
stream of characters. This really was not a problem until users realized they could
have more than one thing going at once. To help users sort out what came from where,
windows were born. Each window contains information relating specifically to the topic
of interest of that window. For example, if you are editing a document in one window,
you could receive mail messages in another while watching system utilization in yet
another. Thus, since someone got frustrated with having input and output streams all
mixed into one, windows now allow separating these streams in a sensible manner.
One element of the Macintosh interface that can be frustrating is the manner in
which scroll bars operate, e specially if the window uses two scroll bars, one for
vertical and the other for horizontal movement. In the extreme case, consider a
window containing a very large picture which takes a substantial amount of time to
redraw whenever you move around with the scroll bars. If you are positioned at the
top-left corner and want to move to the bottom-right corner, you are obligated to do
one of two things.
First, you can move the cursor all the way to the bottom-left of the window and
drag the horizontal thumb all the way to the right, move to the top of the vertical scroll
bar, and move its thumb all the way to the bottom. This approach requires a great deal
of mouse movement and two window updates. Remember that updating the window can
take a good amount of time (depending on the complexity of the document). To make this
situation worse, the user has no visual confirmation of what might be at the
bottom-right of the document.
The other approach that you might be familiar with is the Show Page goodie in
MacPaint. In this approach, a new window appears and a miniature version of the
document is drawn. You can then move a rectangle around to show where you would like
the window to be positioned. Then you hit the OK button or the Cancel button, the
window goes away, and your document window reappears, showing the area you selected.
This does overcome the need for a mental picture of the whole document. While this
method only requires updating the window once, it has the unfortunate problem of
introducing a new mode to the user. In Apple's Do's and Don'ts of a Friendly User
Interface, over-using modes is the first Don't.
The problem then is a matter of giving the user some idea of what the document
looks like and permitting easy access to any part of the document. Other approaches
have been implemented, many of which have contributed to the ideas that go into the
solution given here. This solution not only solves the primary problem, but it draws
from a number of elements of the Macintosh interface that are already very familiar,
hence the name: The Pop-up, Two Dimensional, Random Access, Scroll Bar Menu, or
simply, OverView.
How OverView Behaves
It behaves just as it is named. At the user's request (discussed later), something
akin to a menu pops up. It has the proportions of the document and it contains a
miniature picture of the document. The area currently showing in the document window
is highlighted. As long as the user holds down the mouse button, a gray rectangle the
same size as the highlighted area moves around with the cursor, showing the area that
will be selected if the button is released. Like most Macintosh controls (e.g. the scroll
bar thumb), if the cursor is moved too far away from the window, the gray rectangle
disappears. If the mouse is released when the rectangle is gone, the Pop-up window
disappears and nothing happens. If, on the other hand, the button is released while the
gray rectangle is showing, the old selection dehighlights and the new selection flashes in
the same way that menu selections flash when selected. The scroll bars change
appropriately, and the program gets notified that it needs to redraw the contents of the
window at the new location via an update event.
With OverView, the user never perceives a change in mode, yet has access to the
whole document in one easy step. Like pull-down menus, OverView will not generate
activate events. It will not create update events unless a new selection is made. It
appears quickly and disappears quickly. While it may seem complicated after reading
this description, try using it once. It is much easier used than described.
Summoning OverView
OverView was created to view large typeset pages at varying levels of
magnification. As such, it was designed to be used in a passive mode. That is, the user
could only view, not change the document contents. This has an important relationship
to how OverView was first used. Since clicking in the window pane (the area of the
window where the actual document is, excluding controls) had no implicit meaning, that
was used to activate OverView. However, in documents where text editing or object
editing (e.g. MacWrite, MacDraw) takes place, clicking in the pane has other meanings.
Another method of summoning OverView is called for. Andy Hertzfeld gets credit for the
idea of putting an eyeball icon at the bottom-left of the window and scooting the
horizontal scroll bar over to the right. Clicking on the eye could summon OverView.
Another possibility is similar to the zoom box capability added in the new ROMs. The
eyeball could be placed in the title bar between the close box and the title. Clicking on
the eye would function almost exactly like a pull-down menu.
Making the choice on this is left to you, the creative program designer, to see
what users like best. Keep in mind that it gets tiresome having to move the cursor to an
exact point on the screen to use a function, e specially if you happen to spend a lot of
time far away from that spot. That was the beauty of the very first approach, because
it was always available whenever you were in the window of interest. A typical
power-user trick could come in handy for non-passive windows. Perhaps Option-
click or Command-click or Command-Option-click could be used (as in PageMaker™).
Operational Details
OverView has a few very special features. Some were mentioned above. Others
are listed here. For example, the pop-up window always remains within the
boundaries of the front window. This is important for the pr evention of the generation
of update events. OverView knows that the only window it will ever affect is the front
window, so it can easily convince that window that it was not affected (see the code).
OverView provides flexibility by taking advantage of the information available to
it about the front window. By looking at the size of the window pane and comparing it to
the size of the document, it scales the rectangles appropriately. It also takes advantage
of the available screen size (just in case bigger screens just happen to come along).
Every window which will have its own OverView Pop-up needs a WindowPtr and
a BitMap. NewOverView works by creating a new window for the Pop-up window. It
then creates an offscreen bitmap into which a miniature of the document can be drawn
with UpdateOverView. Then, whenever it is summoned, OverViewSelect makes its
window appear after saving the bits underneath it into a temporary bitmap. It shows
the Pop-up window without deactivating the document window by using ShowHide and
some trickery. It copies the offscreen bitmap miniature into the OverView window and
calls TrackGrayRgn to get the user's selection. It then hides the window, restores the
bits underneath the Pop-up window, and sets the scroll bars based on the new selection.
The Interface
The code is broken up into three procedures: InitOverView, UpdateOverView, and
OverView- Select. The code is in the form of a Macintosh Workshop Pascal (MPW
Pascal) Unit, which can be compiled separately and linked in just like any of the
Toolbox Managers. For now, it is enough to know that MPW Pascal is essentially Lisa
Pascal. OverView was initially written in TML Pascal as a straight program. The
conversion to MPW Pascal took five minutes and was mostly changing the include files
and compiler switches. For more information, see the MPW Section below.
NewOverView should be called once for every window that will have an OverView
window. Pass in an empty bitmap, an empty window pointer, a rectangle with the size
of the virtual document (origin at 0,0), and a size factor (a real number between 0 and
1). NewOverView creates a new window whose height is determined by the available
screen height multiplied by the size factor. NewOverView creates an offscreen bitmap
and fills in the BitMap's record.
It is your program's responsibility to keep the miniature picture up to date. You